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ABSTRACT 


This thesis reports the results of an investigation of the 
apolicability o f pagina and segmentation to memory 
management in modified UNIX operating systems on the 
POP=11/50 minicomputer system at the Naval Postgraduate 
School Signal Processing and Disolay Laboratory. Two memory 
managers are specifically considered: a partitioned 
segmented memory manacer that was desianed and implemented; 
and a simpler, segmented memory manager that was designed 
based on the performance of the partitioned seaqmented memory 


manager. Recommendations are given for future work. 
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Lee NT ROU Cy ON 


The Naval Postgraduate School Signal Processing and 
fees lay Laboratory (1) is used for cesearch and education 7a 
the areas of operating systems, computer graphics, s1qnal 
processing and hybrid computing. The laboratory's edauipment 
momriguration is illustrated im Fig. 1. fhe system 1s bun lt 
around two Digital Equioment Corooration PDOP=-11/50 
processors that share some memoryr some peripherals, and 
access to a signal processing subsystem consisting of a 
Computer Signal Processors Incorporated CSP 125 controller 
with an array processor and an analog to diqital converter. 
The peripheral suite may be divided into two major grouos: 
me data acquisitiom group and the display group. The 
emesp lay aroup consists of Aen Graphics disolay uNIts 
that are designed to support realstimer interactive 
apolications. ihe datas acquisition GrouD “eons: sts o f 
terminals, disks, tapes, and unit record equioment that 
serve the dual purposes of supporting a healthy environment 
for program development and providing for the acquisition of 


data for the graohics and signal processing apclications. 


Choosinq an operating system for the laboratory 
presented significant challenges. Traditionally, real-time 
operating systems have orovided poor environments [om 


program development. The operating systems that are 
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responsive to the demands of orogram development have 
provided very poor realetime and interactive environments. 
When the equipment was acauired, no single PDP-11 operating 
System met all the needs envisioned for the laboratory. It 
would not have been surprising if the decision had been made 
to support separate operating systems tailored to the 
demands of the two areas. Because of the difficulties 
fanerent in maintaining and scheduling multiple operating 
Systems on one comouter system, it was decided to attempt to 
develoo @ unified operating system having specialized 


Subsystems to support both foreground real-time, interactive 


processing and background orogram development processing. 


The baseline ooerating system selected was UNIX, a 
time-sharing system develooed at Bell Laboratories. One of 
the imoortant advantages of UNIX was that Source code in a 
high level language was furnished with the system. The 
availability of source code and UNIX's excellent support for 
program develooment promised a climate favorable to the 


anticioated system modifications. 


The UNIX system has proved to be a good selection. 
Several porojects designed to augment UNIX are in proaress or 
have been completed. One area of particular concern has 
been memory management. Figure 1 reveals that the several 
different types of memory in the confiauration present some 
unusual memory management orobdlems;s; but the figure does not 
reveal the complex memory management oroblems introduced by 


the real-time applications, esoecially those involving 


Hee 





direct memory access Cy display devices. Some of these 
oroblems have been aporoached in earlier work [2], (3), (4). 
One area of interest that had not been investigated prior to 
this thesis was the aoplicability of advanced memory 
management techniques to the laboratory operating system. 
This area was particularly attractive because the PDP=#11/50 
Processors have a Memory Management Unit caoable on 
supporting relocations, odagina, and some segmentation. The 
purpose of this thesis 1S to present the results of an 
investigation into the suitability of segmentation = and 
paging in the modified UNIX operating evironment” at the 
Naval Postgraduate School Signal Processing and Disolay 


Laboratory. 
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li. tHE webe- 14750 


4A. GENERAL ARCHITECTURE 


The PDP-11/50 (5) is a powerful, medium scaler general 
purpose, Lo-bit minicomputer. It is well designed to 
suoport multiprogramming or real-time apolications. Its 
features include a priority interrupt structure, two general 
Durpose register setsr, and three processor states (Kernel, 
Supervisor, and User). Two of the most important aspects of 
the PDP-11 architecture are its inout/output schemenene its 
dependence on Orocessor stacks. Both of these have 
Important impacts on the memory management methods 


considered in this thesis. 


[nelmost Imoortant component of the POre=ll inout/voutour 
scheme 1s) tne) UNITSEUS-. The UNIBUS is a high speed, 
bidirectional, asynchronous bus that connects the CPU, 
perionerals, and memory. Devices attach to the UNIBUS with 
hardware control and data registers that have simulated 
locations assigned jin the upoermost 4,096 words of the 
address space. This simplifies the programmina Ont 
peripheral devices because no special class of inout/output 
instructions is required. Data and control information 1s 
entered into or retrieved from tne devices’ registers as if 
they were actual memory locations. The UNIBUS can be 


controlled either by the CPU or by a pvericheral device. 
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This makes it possible for the devices to access main memory 
with almost ao processor interventton. Jhe arbiterationeumat 
that assigns control of the UNIBUS to a requesting device or 
CPU gives maximum priority to a direct memory access request 
from a peripheral device. Because the PDP=#11/50 does not 
feature a lock and key memory protection scheme, the 
protection of the operating system from OMA devices 1S _ a 


significant memory management problem. 


A PDP=-11 stack is an area of memory set aside under 
Sreaaram contro!) for temporary storages, subroutine linkage, 
and interrupt service linkage. In coneeot, it 1s a Classic 
mibast—in,»s first=out" stack of the type described in ref: 
(6). Each orocessor state has a register specifically 
designed to be its processor stack pointer. The intructions 


that are provided for standard POP-11 routine linkage and 


LA | e 


interrupt handling “push”" and p0N parameters, linkage 
informations, and status informations, using the current 
processor stack. Other “instructions are  oprovidedeato 
facilitate stack manioulation. eR Ome mm: y used, stacks 
Drovide automatic nesting of Subroutines, reentrancys and 
recursion. They also help to decrease the overhead that is 
inherent in linkage and interrupt processing. The only 
major disadvantage of using stacks is tarait prooerly 


controlling dynamically arowina and shrinking stacks is a 


Significant memory management problem. 
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Be. MEMORY MANAGEMENT FEATURES 
lex Concepts 


Even though the PDP=-11/50 computer has a 16"*bit word 
length, its basic addressing logic uses an 18-bit direct 
byte physical address. In the PDP=-11/50 system's simplest 
Gontigqurations the two'most sSicnificant bits of ther lo —=on 
address are not imolemented. The address space is limited to 
32K words (32 * 1,024 words). The address space is used to 
reference up to c8K words of main nemory and the 4K words of 
UNIBUS device registers. To expand main memory beyond 28K 
bytes, the PDP=-11 Memory Management Unit (MMU) must be added 
to the configuration. This unit interprets l6"bit addresses 
as ee cuen addresses from which jit constructs Po Saat 
physical addresses. Up to 124K words of main memory can be 


made adaressable with the MMU, 
Ce Address Formation 


With the MMU installed, the PDP=-11/50 supports two 
32K word virtual address spaces for each of its three 
processor states. Each state has an Instruction Space ([- 
space) and a Data Space (Dspace). Instruction fetches, 
index words, absolute addresses, and immediate operands 
reference I-space. All other references are to D-=space. 
The MMU constructs physical addresses using the information 
in six sets of relocation and descriptor registers. The set 
used depends on the orocessor mode and the type of address 


reference. These registers and MMU contro! registers are 
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assigned simulated memory locations and may be accessed in 
the same way as UNIBUS device registers. Each register set 
consists of eight Page Address Registers (PARS) and ergnht 
Page Descriptor Registers (PDRs). Address formation is 
Shown in Fiqe. 2. The MMU subdivides each 1l6"bit virtual 
address into three fields: the displacement in block (DIB), 
bits 0 to 5% the block number (BN), bits 6 to 123 and the 
active page field (APF), bits 13 to 15. The APF is used to 
select a PAR. The twelve low order bits, or page address 
field (PAF), of the PAR are added to the BN to forma le-bit 
ODhysical page block number (PBN). The DIB is concatenated 
with the PBN to form the 18-bit ohysical address. There are 
two very important implications of this scheme: the basic 
granularity of the memory is the 64-byte block and a page 
may begin on any bolock boundary in the memory. The concect 


of the page frame is not applicable to the PDPH1i1. 
3. Access Contro! 


The PDRs are used to control access to pages, to 
soecify their lengths, and to provide memory management 


data. The format of a PDR is shown below. 


15 14 8 


1 some> "4.3 2 0 
edo dofvvrnfeo ace 


Figure 3. POR Format 


The fields in the PDR are: the access control field (ACh 
Brcs 0 t0 ¢, the expansion difection bit (EDJ, bit 37 the 


mri ttemeort) (40, bit 6G- the accessed bit (A), bit 73 and “the 
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Sage length field (PLF);, bits 8 to 14. Among access. coriens 
that may be specified in the ACF are: read onlysr, abort on 
writes read/writer, no aborts?r and non-resident, abort all 
accesses. Because a Page need not be a full 128 blocks in 
length, the PLF and the ED bits are hee to validate the 
virtual BN before memory access is permitted. If the ED bit 
is not set, the PLF is the page length in blocks minus one. 
In this caser any attemot to access this page with aie aN 
emeater than the PLF is aborted. The ES bit is to be set 
when the page contains a stack extending downward from the 
upper end of the page's address range. Diet me UMD tis 
set, the PLF is 128 minus the page lenath in blocks. In 


this caser any attempt to access this oage with a BN less 


Gem the PLF is aborted. 


The MMU provides a mechanism by which a Kernel mode 
Supervisory routine may be invoked when a memory management 
abort occurse Enough re eeaeten is preserved in MMU status 
registers to describe the tyoe of abort and to identify the 
offending instruction and address. This feature could be 
used i1n a demand paged memory manager, for examples to 


resolve page faults. 


The W and A bits provide page reference data for the 
memory management software. The W bit is set if the page 
has been modified since the PDR was loaded. The A bit is 
set if the page has been accessed since the PDR was loaded. 


Both bits are reset whenever the PDR is modified. 
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Ill. THE UNIX TIME*SHARING SYSTEM 


eee CONCEPTS 


UNIX (7) is a terminal oriented, interactiver time- 
sharing, operating system develorved at Bell Laboratories for 
use on the PDP-1i! family of minicomputers. Most of UNIX is 
written in "C,”™* (8) a high level language also developed by 
Bell Laboratories. A small part of UNIX is written in "as," 
[9] a Bell Laboratories variant of the POP=-11 assembler 
language. Among the most significant of UNIX's features 


ares a hierarchical file system, a device independent 


input/output scheme, and multistasking. 


The basic unit of work under UNIX is the process. Fach 
process 1S an execution of a program file from the UNIX file 
System. When UNIX "bootstraos" itself into memory at system 
initiation time, it "“handcrafts”™ the first two orocesses: 
process 0 and process 1. Process Of which may be thought of 
as an execution of UNIX, is the master control process. 
Process 1 sets up the system; all subsequent processes are 


Gescendents of process ll. 


All processes except process 0 execute in User processor 
State. I f a process reauires service from UNIX, it 
communicates its request by means of a system call. system 


calls are mechanized by use of TRARr “IASt ructions When 
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interrupt the processor, chanae the processor state to 
Kernel, and cause the apororiate service routine to be 
executed. NAhen the system call completes, it returns to the 


calling process with the processor in User state. 


A process creates descendents by use of the "“fork" 
system call. This system call creates an exact dup Veatenor 
the calling orocess. The new process is referred to as a 
child process and the original crocess is err re as 2 
parent process. fhe parent may continue to execute, perhaos 
creating more childrenr or it may use the "wait" system cal] 
to suspend execution until its emia has completed 
execution. The child may continue to execute the same 
program as its parent or it may invoke a new program by use 
of the “exec™ system call. A child may also create children 
o f 1tS Own. Nhen a child completes processing, mt 


terminates by means of the "“exit™ system call. Among other 


actions, “exit™ notifies the parent of the child's demise. 


Process | begins its role as grandsire by creating one 
child for each terminal in the system. Each child opens its 
assigned terminal, sends a messaqe Foe ueon inc €@user to log 
1Mr and awaits a reply. When a user successfully comoletes 
the log in procedure, the child invokes a new program called 
the Shell. The Shell interprets commands specified by the 
user and creates children which invoke other orogqrams to 
carry out the user's commands. When the user logs offs his 
teminal's Shell] orocess terminates. Process tir which has 


been patiently waiting for this to hapoen, is notified and 
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it creates a new child for the terminal. The new child 


reopens the terminal and sends another log in request. 


B. MEMORY MANAGEMENT 


In concent, the UNIX memory manager 18 a relocatable 
partitioned memory manager [10] with swaoping and limited 
segmentation. Each process has an image that must reside in 
€@ contiguous partition while the orocessor 1S executing on 
Bemaif of the process. The image remains 1M memory during 
the execution of other processes unless 1t must be ie eee 
out (Swapped out) to a direct access device to satisfy the 
memory requirements of a higher DPIOFILCY ~Processe 
Relocation and storaaqae protection are accomplished with the 
MMU, When the orocessor iS executing on behalf of a 
process, the memory management registers are loaded so that 
the process can access only itS Own image and, if 
apolicable, a text segment shared with other oprocesses. 
Because a omrocess executes in User moder its adoaoress space 
is the User address spaces however, a part of the process's 
image called the UVECTOR is established in Kernel Dspace. 
The UVECTOR contains process status information needed by 
UNIX and the Kernel mode processor stack to be used while 
the process 1s active. Not all porocess control information 
is located in the UVECTOR. Information that must remain 
acdressable even when the orocess iS not executing remains 
resident for the life of the orocess in Kernel Om=space in a 


control block called a PROC. If the process shares its text 
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with other processes, its PROC contains a pointer to yet 
another control block resident in Kernel O-space. This 
geatrol block is called the TEXT Qeelt conitains intemmation 
that UNIX uses to control the sharing of the text segment. 
APPENDIX A contains detailed information on the UVECTOR, 


emoe, and TEXT. 


A process's image is created when "“fork" copies its 
parent's image. Whenever a orocess uses "exec" to invoke a 
new program, the process's image 1S recreated according to 
specifications in the program file to be executed. A 
process's image differs depending on whether or not it 
shares text. The image of a text sharing process consists 
of its UVECTOR, data, and User mode processor stack. The 
Shared text is established in memory independently of the 
images of the processes Sharing ite In the image of a non- 
sharing process, the text 1S lumped toaether with, and 
considered to be part of, the data. If the process shares 
text, "exec" checks to see if a cooy of the text is 
available in the system. If it is not, "exec" establishes a 


CODY e 


The User address sonace of a text sharing process may be 
established tn two different ways: seoarated instruction and 
data spaces or combined instruction and data soaces. The 
User address space of a non=sharing process may only be 
established with combined instruction and data soaces. If a 
process's address spaces are combined, its I-space and D- 


Space are identical. A separation flaq, determined by 
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"exec" from the file tyoe and kept in the process's UVECTOR, 
controls the method used to establish the address space of a 
text sharing process. If a process's address soaces are 
Separated, its shared text segment is addressable beginning 
at User I*space address 9 and its data is addressable 
beginning at User Despace address 0. If a combined process 
has shared text, its shared text segment is addressable 
beginning at address 0 in both User I-*space and User D- 
space; and its data is addressable beginning at the first 4K 
word boundary (page boundary) beyond the end of the text in 
both User I-space and User Ow-space. If a combined process 
does not have shared text, its text is addressable beginning 
at address 0 in both User I-space and User O-space; and its 
data is addressable beginning at the first word boundary 
beyond the end of the text in both User I-space and User De- 
space. A process's stack is addressable extending downward 
from the highest address in User D-soace or in I-space ana 
Despace. The access control spvecified in the PDRs of shared 
text pages is read only. Al?! other pages, ineluding non- 


shared text, are readewrite access. 


There are two system calls that a process may use to 
change the size of its image without invoking a new Program. 
These system calls are "“ork"™ and "“sbrk" (11). These are 
used to increase or decrease the size of the process's data 
area. They are used mainly in programs with storage 
requirements that have great variations depending on input. 


The size of a process's image may increase in another way. 
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I f its User mode processor Stack grows beyond the space 
initially allocated to it, UNIX dynamically increases the 


amount of memory provided. 


Pa INeUESOUTPUT SYSTEM 


1. Standard Input/Output 


The UNIX standard input/outout (1/0) system [12] 1S 
designed to separate the user from device dependencies,r to 
keep control blocks out of the User address space, and to 
oreserve process relocatability. Two classes of devices are 
supported under the standard I/0 system: character-devices 
and block-devices. Character-devices are read and written 
one byte at atime using a UNIBUS dev 1 Ce Leg) Streiuacmc: 78 
port. Block-devices are read and written in Si2d byte blocks 
uSINgG direct memory access (DMA). UNIX provides the 
expected system calls to create,s open, access, and close 
files on both device types. It also provides buffer areas 


in Kernel De-soace for characterrdevice [/0 queues and for a 


PD00!] of block device buffers. 


Nhen a process requests a write to a character= 
device, an I/Q supoort routine (device driver routine) moves 
the data to the device's output queve or directly to the 
device. When a process requests a character-device read, 
the device driver receives the data from the device and 


moves it to the User address space. 
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When a block write 1S requested, the device driver 
acquires a buffer from the pool in Kernel] Despace, moves the 
data from the User adaress space to the buffer, and olaces 
the buffer on the device's output queue. When a block read 
is requested, the driver places the request in the device's 
input queue, and acquires a buffer to which the device wil] 
transfer the data when the request 1S honored. After the 
device has transferred the data to the buffer, the aeuvee 


moves the data to the User address soace. 


The significance of standard I/0 from the memory 
management point of view is the way in which it localizes 
DMA accesses to Kernel De-snpace. This 18 important because a 


DMA device must be given the ohysical address of the area 


from which or to which the data will be transferred. ia 
Kerne] D=-space, virtual and ohysical addresses are 
identical. Al) addresses used to move data between the User 


address space and the Kernel] D=space are virtual; no device 
or routine needs to know the physical address of the 
requestina process's I/0 area. This means that standard I/0 
is completely compatible with dynamic relocation of the 


requesting process. 


Cc. Raw Block-device Input/Output 


Raw block-device I/0 [12] is a scheme whereby I[/0 
takes place directly between the requesting process'’S memory 
and the device. The advantages of this tyce I/0 are that it 


allows the use of blocks larger than 5Sl2 bytes and that it 
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avoids the overhead of moving the data between the User 
address space and the Kernel) Dspace. Although it might 
seem that the data moving overhead would be small, this is 
not the case because the PDPeli lacks a block=move 
instruction. The only way to move a qroup of data words is 
with a proaram loop. This means that several instructions 
must be’ fetched and executed to move each word of data or, 
in some cases, to move each byte of data. The major 
disadvantage of this type of [/0 is that the block=device 
must be given the physical address of the input or output 
area jin the User address spaces thuSsr the requesting process 
must be "“locked" in memory during the I/0 operation. This 
orevents the memory manager and process controller from 


making optimum use of system resources. 


In practices raw 1/0 does not have an important 
effect on operating system performance because it iS very 
rarely used. [t is important because future applications 
will use it and because supporting it oresents some 


difficult memory management probdlems. 
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IV. MEMORY MANAGER DESIGN 


A, SEGMENTATION 


The fundamental ocroblem addressed in this thesis 185 a 
pragmatic one: how best to modify the UNIX memory manager jn 
order to make nore complete use of the capabilities of the 
available memory management hardware. Shared text 1s 
already well segmented in UNIX, so the first step taken was 
determining a good method of dividing the process image into 
segments. The important considerations were that the 
segments be logically Separate and inaependently managable 
im main memory. It oroved to be possible and desirable to 
use the natural division already discussed: UVECTOR, data 
(ymeluding non-shared text), and the User orocessor stack. 
lemma aivision has the apoeal of beina Straightforward and of 
being an efficient wav of coving with the problem of 
managing the dynamic size changes of the data and stack 


afe@as « 


A study of the UNIX system showed that reestablishing 
the process image when the data or stack changes size is a 
major source of memory management overhead. Whenever either 
the stack or the data changes size, the UNIX memory manager 
has to acquire memory for an entire new image and copy the 
UVECTOR, data, and stack to it. The cost of this copying is 


about 10 micro-seconds of crocessor time oer word if memory 
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is available for the new image, and several seconds of 
elapsed time if memory has to be acquired by Swapping other 
processes out of memory. If changing size were an 
infrequent occurrence, this cost would not be excessive but 
studies have shown that some of the most commonly used 


programs chanaqe size often. Among these programs are: "cc, 
the "C" Janguage compilers "“ed," the text editor; and "as," 
the assembler. With the data and stack in * Seoarate 
segments, overhead is reduced because only the segment that 
changes size has to be copied. If the segments were divided 


into pages, only the last page of the segment would have to 


be copied, reducing overhead even more. 


There 1S another important reason for establishing 
Separate segments for the data and the stack. several 
applications [1] Olanned for the Signal Processing ' and 
Display Laboratory wil] require a memory manager that can 
place a process's data segment in a specific area of main 
storage. specific placement will be required to reduce the 
overhead of orocessor to processor and processor to device 
communication and to orotect processes from destruction by 
errant operations by DMA devices. An example is a process 
that requires the CSP 125 array processor. The CSP 125 can 
access only a portion of the memory available in the 
laboratory system. Any process that communicates with the 
CSP 125 musty therefore, have its data segment olaced within 


the memory that the CSP 125 can access. 
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Another examole 1S a realetime Graphics orocesS uSING 
the Vector General 3D3I display unit. This DMA device 
retrieves and interprets its display list forty times oper 
second. Instructions in the display list can cause the 
device to store data anywhere within the 32K word memory 
segment containing the list. To BO aeemenie UVECTOR and 
Brae x of the process using this device, the display Jist 


must be isolated in a 32K word memory seament. 


Be ALLOCATION OF MEMORY 


After the method of segqmentation was oaecided,, the 
specifics Or the memory allocation technique were 
considered. It was assumed at first that a paged segmented 
memory manager [13] would be the best choice. After careful 


considerations a partitioned segmented memory manager was 


chosen. Partitioned segmentation 1S a variant of paged 
segmentation first suggested by Randal! C14] based on 
simulation studies of simple segmentation and caged 


segmentation. The differences between paged and partitioned 
segmentation ares the basic auantum of storage allocated and 


the method of pohysical address formation required. 


The allocation quantum 1n caged seqmentation is the page 
frame, an area of memory large enough to hold exactly one 
virtual page. Each reauest for storage 1s the same s$12e 
(page size) and each free area is an integral multiple of 
this size. This strategy reduces the loss of storaae due to 


external fragmentation because no area of free Storage 1s 
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ever too small to satisfy a request for a page of memory. 
rt also simolifies the memory allocation and deallocation 
orimitives because they need to respond to memory requests 


of only one size. The disadvantage of paged allocation is 


that even a partial virtual page is allocated a full page 
frame. The unused memory in oadqde frames allocated to 
partial pages causes a loss of usable storage called 


internal fraamentation. 


The basic vdeo behind partitioned segmented seal ccation 
1s the reduction of internal fragmentation. A partitioned 
segmented memory manager allocates storage in a quantum that 
is smaller thanr but an integral divisor of, the page size. 
The largest contiguous area allocated is eaual to the page 
$1zer but,y when memory 1s allocated for a partial page, only 
the smallest number of quanta larger than the size 1s 
allocated. Interna] fragmentation stil] occurs bdut the 
average loss per partial page is only half a quantum rather 
than half a page frame. There are two disadvantages of 
partitioned segmentation: the memory manager must be more 
complex because it must respond to requests for a number of 
different memory sizes and external fragmentation will 


©CGCCUP. 


Physical address formation in a paged segmented system 
1s simple because pages reside in memory at physical 
addresses that are integra! multiples of the page  $ize,. 
Because the page $12z2e 18S always chosen as a power of two, 


the ohysical address is formed from the virtual address by 
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concatenating the virtual address's disolacement-in-paqe 
with the physical page frame number. In a partitioned 
segmented system, pages are placed in memory at physical 
addresses that are integral multioles of them =aU@ant Uc o) 
allocation. Because the quantum of allocation is chosen as 
a power of twor the physical address is formed by adding the 
ohysical page quantum number to the virtual address's 
Quantum=within-page and then concatenating the virtual 


address's displacementewithin=quantum with the result. 


Because the PDP-ti/50 MMU can Support either a paged or 
partitioned segmented memory manager, the important 
consideration in deciding between the two memory managers 
was: how the loss of storage utilization caused by external 
fragmentation with a partitioned segmented memory manager 
would compare to the loss of storage utilization caused by 
internal fragmentation with a paged segmented memory 
manager. A definitive answer to this question is not 
possible unless both memory managers are testeds however, it 
1S eaSy to show that the storage losses with a paged 
segmented memory manager would be unacceotadle in the UNIX 
environment. The argument for this premise is based on the 
very large (4K word) page size imposed by the memory 
management hardware, the extremely smal] number of paaqe 
frames available, and the small Segment sizes that result 
when the orocess image 18 divided into ‘Ca weres se Omemn sie The 
most Important consideration 1s the comparison between 


segment size and page size. If the segments were very large 
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compared to the pages, the percentage of partial pages would 


be smal] and the resulting . loss Of utilization 
iasiagnificant. If the segments were small compared to the 
pages, almost all pages would be partial pages and the 


resulting loss of utilization would be high. 


The UVECTOR seqment is fixed in length at .on oWwormese 
The initial stack segment allocation for all processes is 
~-64K words. Stacks grow dynamicallyr but oboservations have 
Simeown that this is a rare occurrence. Estimates of the 
average sizes of the text and data segments were determined 
by examining the program files of 70 frequently used 
programs. The mean text segment size was determined to be 


1.9K words and the mean data segment size at the start of 


execution was determined to be 2.ceK. Data segments 
frequently grow but the largest increase that has been 
observed is about o- ) WORdSmITCr Cone phase Wot the — 5 
compiler. Even making the generous assumption that average 


combined data and stack growth is .5K, these figures’ show 
Ehat the paged segmented memory manager would waste more 
memory than it used productively. It would allocate four 
pages (16K words) for the averaqe shared text process of 


which an average of 5.7K words would be used. 


The segment size data is comoletely counter to 


experience qained in large scale comouter systems. It was 


completely unexpected. Because the mean segment. sizes 
observed were all less than a page, doubts were raised about 
the desirability of selecting any memory management 
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technique more complicated than simple segmentation. In 
spite of the doubts, it was decided to continue with 
develooment of a UNIX with a partitioned segmented memory 
manager (PSUNIX). It was believed that this effort would 
best serve to explore all memory management options. Design 
work was started, however, on a version of UNIX with a 
simple seqmented memory manager (SUNIX). SUNIX was to be a 
falleback position if the oerformance of PSUNIX oroved to be 


unsatisfactory. 


Nhen the partitioned seaqmented memory manager was 
chosen, the only remaining design question was the size of 
the quantum of allocation. The 64-byte block, the smallest 
Quantum supported by the memory management hardware, was 
selected. This choice was based on the pir ae cileal 
consideration that it required no change to the existing 


UNIX memory allocation and deallocation orimitives. 
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Ve. MODIFICATIONS TO UNIX 


A. OVERVIEW AND PHILOSPHY 


Modifying the UNIX memory manager to oroduce PSUNIX was 
a formidable task that reauired writing aoproximately $00 
lines of new code and comprehending and modifying existing 
programs totaling more than 1,800 lines of code. The 
approach that was taken to this Oroblem was to avoid putting 


large sections of new code into existing orograms. The new 


code that was needed to support the memory manager was 


centralized in severa|] smal | self-contained fUMCti ons 
(orimitives). Wherever possibler changes to existing 
routines were limited to removing calls to the old memory 


management primitives and replacing them with calls to the 
new memory management orimitives. The -goals™ -Of = this 
approach were to make the the general structure of memory 
management in PSUNIX seem familiar to those who understood 
the UNIX structure and to simplify debugging by localizing 


new code. These goals were realized. 


The changes made to implement PSUNIX can be divided into 


five areas: 


tLe EComtro!=bteck “Mody riceat? ens 
Ce. Memory Management Suoport Modifications 


3. Swap Space Allocation Modifications 
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4. Raw 1/0 supcortu4ods fieaaiceas 


S. Support Program “ody ticauvodgs 


Each of these areas is described in a subsequent section of 
this chapter. Supoorting documentation can be found in the 
appendices. APPENDIX A contains detailed information on 
control blocks related to memory management. APPENDIX 8 
contains detailed documentation Ont memory management 
routines found in UNIX, FPSUNIX, and the proposed simple 


segmented version, SUNIX. 


EeecONTROt BLOCK MODIFICATIONS 


The only control blocks modified were the PROC (process 
control) and the TEXT (shared text segment control). No new 
control blocks were added except oage tables which are 
allocated in temporary storage and used as work space during 
memory allocation and deallocation. In “UNIX, ther PROG 
contains the size and address of the image. In PSUNIX, the 
PROC was expanded so that it could fulfill the same role. as 
the MULTICS [{15] Segment Map Table. The image size and 
address were removed and the segment sizes and oage 
addresses were added. In both versions of the operating 
System, the TEXT performs the same function as an entry in 
mre MULTICS Active Seqment lable. The only modification 
required for PSUNIX was the addition of a page address 
array. APPENDIX A provides detailed information on the 
PROC, TEXT», and several other control blocks that gare 


imoortant to memory management. 
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C. MEMORY MANAGEMENT SUPPORT MODIFICATIONS 


The basic form of the memory management modifications 
has been presented in the previous chapter. APPENDIX 8B 
provides complete documentation of the new memory management 
orimitives under the heading "Dage.c." It also provides 
documentation of the chanaes made to existing UNIX programs 


that call these orimitives. Functions) of oarticular 


e. 


interest are: “newproc,"”" which creates a orocess's image by 
copying the image of the process's parent; "execs" which 
recreates a process's image when the process invokes a new 
orogram; "“xalloc,”"™ which establishes shared text segments; 
"expand," which changes a process's image sizer "schea," 
which swaps orocesses into and out of memory; "xfreer" which 


removes shared text segments from the system; and "“exit," 


which terminates processes and frees their resources. 


ieee owAP SPACE ALLOCATION MODIFICATIONS 


The UNIX method of controlling swap space 1s to allocate 
it to a process when the process 18 to be swapped out and to 
free it as soon as the process returns to memory. The 
advantage of this is that it keeps the demand for Swap space 
at a minimum but the disadvantage is that it requires an 
allocation and a deallocation whenever a process iS Swapped. 
UNIX swap I/0 is extremely efficient because the process 
image 1S contiquous 1M memory. bears “altows UNIX to ‘swoaoee 


orocess with one [/0 ooeration. 
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The PSUNIX method of controlling swap soace 1s to 
allocate it to a process the first time the process is 
Swapped out and to allow the orocess to keep the swad space 
when it returns to memory. A process loses its Swap space 
when it terminates or when one of its segments becomes too 
large for the space that was allocated. Inveotn “Versions sos 
— operating system, the orocess is allocated a contiguous 
See Of Swap Space. This reduces the sllocation overhead. 
PSUNIX incurs the overhead of one I/0 operation per page in 
the process's image. This means that PSUNIX has between 
three and four times as much swap I/0 overhead as UNIX for 


the average process. 


The programs concerned with Swanping are documented in 
APPENDIX B. Functions of particular interest are: “xswap," 
which Swaps Processes out of memory; "Swapr”" the swao I[/0 
call; “pswapr" a PSUNIX function that Swaps several pages to 
or from memory? and "prswap," a PSUNIX function that returns 


8 Swapoved process to memory. 


eee RkAW T7/0 SUPPORT MODIFICATION 


As has been described oreviouslyr raw I/0 requires a DMA 
transfer directly from or directly to a process's address 
space. The data is transferred to or from a contiguous area 
of main memory. In PSUNIX this presents a serious problem 
if the data area spans a page boundary because ere pages 
wil] NrOpde|y Mot be — Comey quous. The only efficient 


solution to this problem is to make the pages contiguous. 
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The function “pohysios”™ which sets up raw 1/0 transfers, 
was modified to determine 1f each transfer spans a page 
boundary. When a boundary spanning transfer is requested, 
"shysio” calls “contigs” a memory management primitive, that 
reallocates the data and stack segments of the requesting 
process so that both of them are allocated contiguous 
memorye The process is also flagged as one that requires 
contiguous allocation. Whenever memory is allocated for the 
Process in the future, the segments are given contiguous 
areas of storage. The process remains flagged until it 


either invokes a new orogram with "“exec"™ or terminates. 


APPENDIX B contains more detail on this subject. 


eee SUPPORT PROGRAM MODIFICATIONS 


During the course of this thesis two program development 
tools were perfected and two program errors in UNIX commands 
were encountered and corrected. These programs and 
corrections have been documented elsewhere and are only 


briefly discussed here. 


The program development tools are: an assembly lanquadge 
program to dump memory onto the sSwao file without operating 
System supoort and aC language orogram, CRASH SOAY., to 
retrieve the dump from the swao file and place it itnto the 
UNIX file system. The dump program was made oart of the 
operating system. It was executed from the system contro] 
panel following a system failure to oreserve the contents of 


memory for analysis. This system of taking and retrieving 
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complete memory dumos was extremely valuable. PSUNIX could 


not have been develovoed without it. 


The two proaqram errors were discovered in Ale the 


command for orinting symbol tables of. compiled orograms, and 
ame SyYStix,” the command that adjusts the format of “a SUNT 
operating system image so that it can be “bootstrapped”" into 
memory. The errors were discovered because the PSUNIX image 
exceeded 64K bytes. Neither oroagram executed properly with 
the PSUNIX image as data because both programs used counters 


that overflowed Ae ol re The problem was solved by 


increasing the size of the counters. 
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V1. PEREOR WAG ean wibay 


Bree APERIMENTAL DESIGN 


A series of exoeriments was done to determine the 
mermative performance of the UNIX and PSUNIX versions of Gtme 
operating system under a variety of operating conditions. 
The elapsed execution times of standard streams of processes 
(benchmarks) was chosen as the metric for system 
performance. Two benchmarks were used? a monoprogramming 
benchmark, BENCHI; and a multiprogqrammina benchmark, BENCHe. 
Both benchmarks contained the same processes. Most 
processes chosen for the benchmarks are representative of 
the I/0 limited program development environment bout several 
of them (notably a "Rings of Hanoi" calculation) are 
Oorocessor limited. APPENDIX. € “contains list incs so tamae 
commands in BENCH! and BENCHe. Reference [11] documents 


these commands. 


The computer system used to execute the benchmarks was 
ere "SB" side of the laboratory configuration shown in Fig. 
1. The perjioheral devices used were a single terminal and 
two 1.25 megasword RK0S cartridge direct access storage 
devices (16). The file system for the onerating system was 
mounted on one of the RKOS devices. To reduce I[/0 
contention, the other RKOS device was used for Swapping 


processes ymco and out o f main memory. The main memory 
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available in the system was the oarameter varied rn the 


experiments. 


BeeeeoRESENTALONM@OF RESULTS 


The timing data presented in this section was obtained 
by executing the benchmarks under control of the "time" 
command [11]. The times are determined by sampling the 
processor state at a 60 h2 ratew. "“Real" time is actual 
elapsed test time reoorted to the nearest second. "User" 
time is the time the processor spent executing instructions 
in the User state. "Sys" time is the ‘time that “tie 
processor spent executing instructions in the Kernel and 
Supervisor states. Both "User" and "Sys" times are reported 
to the nearest tenth of a second. The difference between 
"Real" time and the sum of "“User" and "“Sys" times is 
Orocessor idle time. Earlier work [4] suggests that timings 
of the same benchmark may have a standard deviation of as 
much as 8 percent of the mean values. No statistical study 
of these timings was performed in the course of this thesis 
but limited obServations indicate that the deviation 1S much 


mess than & percent. 


Six experiments were performed. The first was. an 
execution of BENCH], the monoprogrammina benchmark, under 
both operating systems. The results of this experiment are 
shown in Table 1. The next five experiments consisted of 
executing BENCHe under both operating systems, varying the 


amount of dynamic memory availible from 32K words to 64K 
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wWoGcGdS ia GOK Word estens. The results of these exoeriments 
are shown in Tables e@ to 6 respectively. Combined results 
are shown in Fig. a, a graph of elapsed times against 


dynamic memory available. 


See ANALYSIS OF RESULTS 


The experimental results clearly indicate that the 
performance of PSUNIX and the performance of UNIX are almost 
identical over a wide range of sizes of available dynamic 
memory. Both the amounts of orocessor idle time and of 
Supervisory overhead are aporoximately equal in all 
corresponding experiments. The aporoximate equality of idle 
times indicates that the disadvantage of increased Swapding 
overhead in PSUNIX is offset by a reduction ie the number of 


processes swapped because of reduced external fragmentation. 


The apeoroximate equality of the supervisory overhead 
indicates that the advantage of reduced segment copying in 
PSUNIX is offset by the increased complexity of the memory 


management routines. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


The most interesting ee of this thesis 1S tivaueee 
confirms the axiom that a simple program is very often a 
Bod orogram. From the standooint of sperformance alone, the 
simoler UNIX memory manager is as efficient as PSUNIX, 
PSUNIX is attractive because it provides an additional 
feature, segmentation, with No performance penalty. 
Peecmough PSUNIX could be placed into production use at once, 
it would orobably be a better idea to proceed with the 
develooment of SUNIX. From the data oresented on segment 
sizes, it apoears that SUNIX will perform at least as well 
as PSUNIX. SUNIX memory management routines wil] have the 
advantages of being both smaller and simpler. Because of 
this, they will require less storager be easier to maintain, 


and cause less memory nanaqement overhead. 


No matter which version is implemented, many parts of 
the memory manager wil] remain ootential candidates for 
improvement. The basic memory allocation orimitive, 
"malloc," is an example. In ref. [6], Knuth suggests many 
possible improvements to the simple algorithm used 1n 
"malloc." Although Knuth's logic is compelling, we may again 
be surprised by the correlation between simolicity and 


goodness. 
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A more important project will be the develooment of the 
system calls that will be used to place a process's data 
segment in specific areas of memory. Successful completion 
of this project will be required before the full benefits of 


segmentation will be attained. 
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APPENDIX At MEMORY MANAGEMENT “CONTE ORS EGG. 


A. DOCUMENTATION FORMAT 


[fi Sweppendix contains documentation Dots thew scomenou 
blocks in the UNIX, SUNIX, and PSUNIX versions of the 
operating system that are direcly or indirectly concerned 
with memory management. The source code for these contro] 
Bitecks 1S found in files in the directory /usr/sys- Each 
control block 1S documented under an upper case roman 
letter. The name of the source code file containing the 
eomt ro | DOCK 15 moted followimag tre control blockumame-. 
Mmemcocumentation of each control Block 15 divided into two 
subsections: overview and significant data elements. Only 
the data elements significant to memory management are 
documented. Because this aponendix was designed to be used 
with a copy of the system code, the data elements. are 


documented in the order in which they apnear in the source. 


In accordance with the non-disclosure terms of the 
software agreement with Western Electric, program listings 
are not provided as cart of this thesis. Authorized users 
of the UNIX ooerating system may obtain machine=readabdle 
copies of programs oroduced for this thesis by contacting 


the Naval Postaraduate School. 
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Bi -COREMAR sy stim 


ee Overview 


COREMAP is an array of structures that keeps track 
of the unallocated areas of main storage. Each structure 
contains the starting ohysical block mumber and the size of 
an unallocated storage area. COREMAP is sorted so that its 
entries are in physical block mumber seauence. See the 
Becumenitation of “malloc.c" in APPENDIX B for descrigotiods 


of the memory management primitives that manipulate COREMAP, 


2. Significant Data Elements 


ae char *mesi2e 


berelises Sa the Size mwof ene free area in 6b64-byte 


BOG KS « 


By Char *m¢eaddr 


This is the memory physical block number of the 
start of the free area. lf this e4melad-1s Zero, 1t Momccetne 


end of COREMAP, 


C. SWAPMAP, systm.h 


Ae Overview 


SWAPMAP is an array of structures that keeos track 
of the unallocated areas on the Swap device. Each strveture 


contains the starting physical sector number and the size of 
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an unallocated area. SWAPMAP 15 Sorted So that ItS5 entries 
are in physical sector number sequence. The same primitives 
used to maioulate COREMAP are used for SwAPMAP, See 


APPENDIX B. 
fepocromiticeant Data Elements 
ae char *mesize 


This ts the size of the free area in 2e56=word 


Sectors e 
Bis enor kmeaddr 


This is the memory physical sector number of the 
Start of the free area. If this field 1S zero, it marks the 


end of SWAPMAP, 


Dameer ROC, coroc.h 
1. Overview 


The array "proc" is an array of Structures referred 
momeas FROCS in this thesis. OQne of these structures 15 
allocated to each active process in the system for the life 
of the process. The array is located in the Kernel address 
Space ano iS oermanently resident in main memory. A 


Orocess's PROC contains all orocess information that cannot 


be Swapped out of main memory. 
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Co. SCM teant (Oat a see menws 
ae Ghar bef lad 


This is a word of flaaqgs. Bit 0 cf thisevor cen 
the SLOAD flag. If it 18 set, the process 15 IN main memory. 
mamta ec Of this word is the SLOCK flag. tt eee 1S set, the 
process 1S locked 1m memory and may not be sSwapped out. Bit 
meen) this word is the SSWAP flag; if it 18 Set, the» orecess 
1s being swapped out. In PSUNIX, Bat 15.0f this “worde secs 
mem flag. [If the bit is sete it means that both the 
process's data and the orocess's stack must be contiguous in 


main memory. 
D4 rAt o¢addr 


This field is present only in UNIX, L faerie 
process is resident in main memorysr it is the physical block 
number of the orocess's UVECTOR. If the process 1S Swanoped 
ot ; Jet 1S Ewe Swap device block number of the swapped 


image. 
eer int pesize 


Meas tielad $s oresenmt omlyonm UNIX. It) “emetne 
size of the orocess's swaocable image measured in 64-byte 


blocks. 
Gis int *petextp 


This is a pointer to the process's TEXT. [ft the 


value is zeror the orocess does not have shared text. 
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e, Int pecador 


This fiela is oresent only in SUNIX and PSUNIX. 
Hr 1s the main memory physical block number of Vthewcnocescue 


EveciOR if the process is in memory. 
i. int ofoadar (8) 


This array is present only in PSUNIX. The 
integers in the array are the memory ohysical block numbers 
of the process's pages. The order of pages is: first data 
pages from low to high virtual address and then stack pages 


from high to low virtual address. 
Qe ine p¢dacdor 


This field is oresent only in SUNIX and PSUNIX, 
it is the swap device block number of the process'sS Swap 


space. If it is zeror the process has No Swap space. 
Pe Int p€dsize 


Tris field is present only im SUNIX and PSUNIX, 


It is the size of the orocess's data in 64=byte blocks. 
ee Int ee¢ssize 


This field 1s oresent vom lly ip oun and Fou. 


it 1S the size of the orocess's stack in 64=byte blocks. 
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a BEX Ths tex t.n 


Fe Overview 


The array "text" is an array of structures called 
[exis in this thesis. Each seqment of sharable code is 
assigqnec a TEXT for the life of the segment. The text 
contains) all data on the usage and status of the seament. 
The “text" array is found in the Kernel!) address space and is 


permanently resident in main memory. 


Ce. Sianificant Data Elements 


a. int x¢daddr 


This ts the Swap device block number of the text 


segment's image. 


vs int x€caddr, int xcaddr (8) 


In UNIX and SUNIX, this 1s the memory physical 
block mumber of the start of the text segment. Lh eR Sui ex 
this array contains the memory physica] block numbers of the 


pages of the text segment. 


Cx int x€size 


This is the size of the text segment in 64=byte 


DOCKS « 
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Gre char x€count 


This 18 the number of processes sharing the text 


segment. 


Ce. char. xeeccount 


This 18 the number of memory resident processes 


using the text segment. 


meme UVECTOR, user.h 


bis Overview 


The structure "user" is referred to as the UVECTOR 
ite this thesise One of these structures 1s parti ct sunc 
Swappable image of each orocess. The UVECTOR contains al] 
process data that is not needed when the process iS not In 
Gemtro: of the processor. When the process is tn control of 
the processor, the orocess's UVECTOR resides at virtual 
Kernel aqata space address 140000 octal. The portion of the 
UVECTOR not used by ovorocess data elements is used as the 


Kernel mode processor stack. 


eC. Significant Data Elements 


ae int ueuisallé6]) 


In UNIX this array e€ontains tne  =G&=byYte Bodoc. 
disolacements from the start of the region of the process's 
data and stack pages. In SUNIX and PSUNIX this array is not 


used. 
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bx int ueuscsdibie) 


This array contains the prototypes of the 
process's user l-space and D-space paqe descriptor 


registers. 


Gre int uetsize 


This ts the size of the process's shared text 


segment. 


ro int ue¢dsize 


lye tse the size of the crocess S caca- 


Ce int uessize 


lhisers etre sizewof the Ofrocess Ss stack. 


G. PAGET, vage.h 


We Overview 


An array of “paget"™ structures is referred to as a 
PAGET in this thesis. This i8 @ page table containing the 
sizes and addresses of the process'S pages. A PAGE Pie 
always organized so that data pages apoear first from low to 
high virtual address followed by stack pages from high to 


low virtual address. 


DD 





CO. Siegnificeant Bats Elemen.- 


ais int tteoaddr 


This is the memory physical block number of the 


Start of the page. 


Bas int t€osize 


This is the size of the paae in 64ebyte blocks. 
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APPENDIX Bs MEMORY MANAGEMENT ROUTINES 


A. DOCUMENTATION FORMAT 


This aopendix contains documentation of functions within 
the UNIX, SUNIX, and PSUNIX versions of the operating system 
that are directly oor indirectly concerneaq with memory 
management. Because this aopendix is designed to be used 
with a copy of the source code, the documentation is divided 
into sections that correspond to the divisions of the source 
code. The UNIX source is divided into several blocks of 
code containing related functions. These blocks of code are 
stored as files in two aGirectories: /usr/sys/dmr for device 
management functions and /usr/sys/ken for the remainder of 
the system. The documented functions in each block of code 
are grouped under an upper case foman letter. Each function 
within each block is listed under an arabic number. The 
functions are documented in the same order in which they are 
found in the code blocks with any new functions anpearing 
last. The documentation of each function is divided into 
the following Subsections: parameters, functional 
description, returned valueSr, and error conditions. Any 
differences in functton documentation among the three 
versions Oi the operating system are noted in the 


acpropriate subsection. 
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Be, mMoaeec 
line sureg() 
an Parameters 


The current process's UVECTOR and PROC are 


imolied parameters. 
bee = Functional Descrrot ion 


This function loads the User descriptor and 
address registers in the memory management unite The 
descriptor registers are obtained from the array utuisdl] in 
the current UVECTOR. Address register loading is controlled 
by the values of uttsize, utedsize, uessize, and ufsep in 
the current UVECTOR. In UNIX the page address registers are 
determined based on: the region address, otaddr, in the 
current PROC; the text segment address, xtcaddr,s, in the 
current TEXTs and the page disolacements in the array 
ueuisal] in the current UVECTOR. The page displacements are 
not used in SUNIX or UNIX. In SUNIX the segment addresses, 
po¢daddr and ptsaddr, are used instead of peaddr. In PSUNIX 
the page addresses in the array otepaddr()] in the PROC and 


x¢caddri{] in the TEXT are used. 
c. Returned Values 


The values returned Dy tiis function are not 


chec ked. 
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Ga Etihorecona itt ons 
This function has no error condi) ome 
e. estabur(nt,nd,ns,sep) 
@. Parameters 


The first three parameters are the sizes of the 
eurrent process's data and stack in 64=byte blocks. fhe 


rn 


value of "seo" is a flag that is set 1f the process has 
solit mstruction and data space. The current process's 


UVECTOR is an implied input. 
Ds Functional Description 


This fumetion filest cheeks the vaillidi ty mot mamas 
arguments. It loads the prototypes Ee the memory management 
page descriptor registers into the array utuisd() ig “the 
current UVES ETO R In UNIX it also loads page start 
displacements in blocks measured from the beginning of the 
region or text into the array ueuisal) mm the current 
UVECTOR., In both SUNIX and PSUNTX, utuisal) is not loaded; 
the values of the parameters are placed in the variables 
ueétsize, ut¢dsize, uessize, and uesep in the current UVECTOR. 
In all versionse "“Sureg()" 318 called to load the actual 


memory management registers. 
ce Returned Values 


If the parameters are invalid, minus one 1S 


returned; otherwise, zero 1S returned. 
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caljer. 
Ste 
rounded 


Giz Error Condi tiiens 


The minus one return indicates an error to the 


nseg(n) 


Be Parameters 


The parameter is a number of memory blocks. 


Ov Functional Description 


This function calculates the number of pages, 


UD» rn the number of blocks specified In the 


parameter. 


POUlTX.. 


Cc. Returned ones 
The returned value is the number calculated. 
Cte rcor Condit ).0ns 
This function has no error candi tions. 
cksize(ntrndrns,sepo) 
a. Parameters 
See “estabur(nt,ndrns,sep)." 
DewnMet Tonal Vescripel6m 
This function is oresent only in SUNIX and 


It checks its parameters to see if they are valid. 
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Cc. Returned Values 


This function returns minus one fot the 


parameters are invalid and zero if they are valid. 
Consors Cond) tions 
A minus one return indicates an error tothe 
Galler. 
Gee malioc.c 
1. malloc (mo,size) 
a. Parameters 


The parameters are a pointer to amap array and 


@€@ size specified in blocks to be allocated from the map. 
De Functional Description 


This function allocates space in main memory and 
on the swao device. If memory is to be allocated, the first 
parameter must point to COREMAP, If swap soace is to be 
allocatedrs, it must point to SWAPMAP,. The amount of space 
needed must be specified in 64-byte blocks if memory is to 
be allocated and in 256=word sectors if swap space is to be 


allocated. 
Ci, Returned Values 


This function returns tne ohysical block number 


ans the space i f allocation 1S Successful and zero if 
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Slocation 1S unsuccessful. 
on Error Conaitions 


A return value of zero indicates allocation 


failure to the caller. 
ee Unrree(mo,S)1ze6;4a) 
ae Parameters °* 


The first two parameters are the same as those 
oe malloc”. The third parameter is a physical block number 


of an area of main storage or Swap space. 
om Functional Descriotion 


This function frees the specified area of main 
Storage or Swap space. If memory 1s to be freed, the first 
parameter must point to COREMAP. If swap space is to be 
freed, it must ooint to SWAPMAP., The size must be specified 
in 64-byte blocks if memory is to be freed and in e56-word 


Sectors if Swao Space 1s to be freed. 
ce. Returned Values es 


The value returned by this function iS not 


checked. 
gd. Error Conditions 


This function has no error conditions. 
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ec Sioac 


Lio Cores 


a Parameters 


The current process's UVECTOR, PROC, TEX) |) wane 


address space are implied parameters. 


or Functional Description 


This function creates a memory image file 
memo isting of the current process's UVECTOR, datay and 
stack. In UNIX this function uses “estabur™ to redefine the 
process's virtual address space to make the data and stack 
Gemti1quous.e It then writes the data and stack im one outpuE 
operation. In SUNIX and PSUNIX this is impossible because 
the data and stack may not be physically contiguous. Two 
output operations are used, one outout operation for: the 
Gata and one for the stack. If an output error occurs. an 


indication 1s left in uferror in the current UVECTOR. 


ce. Returned Values 


This function returns zero if it is successful 


eae ome if an outout error occurs. 


oe ER ROG COne if) ons 


The one return indicates an error to the caller. 
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Cy Orowlso) 


a4 Parameters 


The parameter is the value of the current 
orocess'’s User stack pointer. The current orocess Ss UVeQ Io. 


and PROC are implied parameters. 


bx Functional Description 


This function is called asynchronously when the 
current process's stack attemots to exoand beyond the size 
erlocated to it. This function calculates the number of 
blocks that the stack must be increased, validates the new 
Stack sizer and acquires the memory that is needed. In UNIX 
"expand™ 31s called to establish the new, larger address 
space. In PSUNIX "“sexpand" is called to establish the new, 
larger stack. In SUNIX this fumetion attempts to acaumre 
space for the new stack. If it is unsuccessful, it Camels 
"ceswao" to acquire the space. It 3t Vs sliceess ful min 
copies the old stack to the new and frees the old memory. 
In all versions the newly acauired space is cleared and 
"estabur”™ is called to reload the memory management 


registers. 


ce. Returned Values 


ins fURCT OR returns a zero nt Tat 1S 


unsuccessful and aone if it is successfu). 
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d. Error Conditions 


A zero return indicates an error to the caller. 


eee SlOec 
ioe Sched (|) 
ae Parameters 


The PROCS and TEXTs of al! oOrocesses are imolied 


parameters. 
b. Functional Description 


This function searches for swapped out orocesses 
that "deserve" to be returned to memory. It selects the 
most "“deserving”™ processs acquires space for it by Swapping 
out other orocesses, if necessary, and returns jit to main 
memory. In SUNIX and PSUNIX two new functions are used: 
wee alloc” to acquire main memory for the process and 


"orswap”" to swap jit in. 
ce. Returned Values 


This function does not return, lt VS the Yoeasinc 
yeastruction looo of Process Oa It goes to sleeo and is 


reawakened about once oer second by the clock function. 
Gis Error Conaitions 


In UNIX, if a Swap input or output error occurs, 


the message “Swap error” will be sent to the console and the 
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System wij)l crash. 
Ce nmewproc(nro) 
a. Parameters 


The oarameter is a Sointer’ to a PREG Rete ce 
estadlished for S child  Omocess. The current process's 


UVECTOR, PROC, and TEXT are implied parameters. 
Dee huUnGt tt oOMmal DeSsGcrret lon 


This function creates an exact duplicate of the 
G@errent process as a child of the current process. it first 
makes the appropriate entries in the child and parent PROCs 
and in the TEXT if one exists. It then attemots to acquire 
memory for the child. If it is successful, it simply copies 
the parent's image to the new memory. If it farls, it swaps 
out a copy of the pcarent's image to be returned to memory as 
Mme child. Im SUNIX and PSUNIX, 3 new function, "“pralloc? 
1s used in the attemot to acauire memory for the child. In 


PoemiX anew function “prconoy” 1s used to cooy the Scarent's 


image. 
Cy Returned Values 
This Connect vom returns zero to the parent 
process. The return to the chiladseoels mot come trom un is 
function but from the scheduling function “swtch". The 


child can Polen eqn y itself aS the "ehild cecausSe “Swen. 


returns a one to ite This 18 one of the most important and 
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subtle pohenomena in UNIX. 


Gis Error Conayt ioms 


If the PROC pointed to by the oparameter is 
already allocated to an active orocess, the message "no 
procs” will be sent to the console and the system wil] 


crash. 


3. expand(newsize), expand(newd, news) 


as Parameters 


Im UNIX this funétiom 16 %eallled “with” vou ss woe le 
Oarameter, the new region size.e. In SUNIX and PSUNIX this 
function is called with two parameters: the new data s12e 
and the new stack size. The current process's PROC and 


UVECTOR are imolied parameters. 


Seer unct1TOnmal (leserice ion 


In UNIX this function jis called whenever the 
euze of the current orocess's address space changes. It puts 
the new size in pesize in the current PROC. If the new size 
is smaller, it frees the unwanted storage. If the new size 
is laraer, it attemots to acquire 3 new region for. the 
orocess. If it succeeds, it copies the process's image to 
the new reaion. Tf it fails, it causes the process to be 
Swapped out with the new size noted in its PROC. When the 
process returns to memory, it will return at the new size. 


ie the process is swapced out, this function calls "Swtch" 
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to change current processes. In.._ SUNIX anda Psu tiaeis 
femme t 1 On 1s called only to acquire an address space for sa 
process that currently has only a UVECTOR. In these systems 
1t oeuts the two new sizes in pedsize and pessize in the 
eumrent PROC. In UNIX the function "“xswap” %s Caliieceto 
Swap out the process; tn SUNIX and PSUNIX "ceswap" is used. 
In UNIX, "Sureq"™ is called to load memory management 


BeQisters; in SUNIX and PSUNIX, this its not necessary. 
Cs Returned Values 


The return codes of this function “are unoe 
checked. The caller has no way of determining if the process 
was increased in size directly or by Swappina. In UNIX, i f 
the process is swapped, this function does not return to its 
caller. The return comes from a subsequent call to "“Swtch" 


after the process has returned to memory. 
Lae cror Condtt i oms 
Tats function has mMowerror sconal tions. 
4. ceswaoplods,oss) 
a. Parameters 


The oarameters are the current process's data 


and stack sizes in 64-byte blocks. 
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oe Functional Description 


This function iS present only im SUNT Sang 
PSUNIX. It jis called to do the housekeeping that is 
necessary for expansion Swapping. Ite calls “xswapo" to 
perform the actual SwapOoIng and then it calls “swtch" to 


olace anew process 1m contro! of the processor. 


Gr Returned Values 


This function does not return ta} its caller. 
The return to the caller comes from a subsequent call to 


"sSwtch" after the process has returned to memory. 


qd. Error Conditions 


This functton has no error conditions. 


5. Swfree(rp) 


ae Parameters 


The parameter 1S a pointer to a PROC. 


bs Functional Descriotion 


This function frees any Swap space belonging to 
the process indicated by the oarameter, and it zeroes out 


pedaddr, the pointer to the space in the PROC, 


ce Returned Values 


The values returned by this Funct vom are not 


checked. 
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d. Error Conditions 


This function has no error conditions. 


o. sexpand(news) 


ae Parameters 


The parameter is the new, larger stack size. 


*. 


Dewe augGeteonmal Desecmiot ion 


This function is present only im PSUNTX . ee 1s 
eeried from "grow" to increase the stack size. See the 


description of “*exoand". 


Cis Returned Values 


See “expand"™. 


d. Error Conditions 


See "expand". 


7. dexpand(newad) 


ae Parameters 


The parameter is the new, larger data siZe. 


Or Functional Descriotion 


This function 1$ present only im PSUNITX. elt ers 
called from "“sbreak" to increase the data size. See the 


aescermiotion cf “expand”. 
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ce. Returned Values 


See “expand". 


ae Error Conaitions 


See "expand". 


See conmt tore) 


ae Parameters 


The parameter is a pointer to the current 


orocess's PROC. 


re Functional Description 


This function ieVeresent only im Poul) < ee ees 
called from "physio" to make both the stack and the data of 
the current process pohysically contiguous In Main Storage. 
It indicates that the process requires contiaquous sSeaqments 
by setting the CONT bit tn the peflag in the crocess's PROC; 
then it attempts to acquire physically contiguous main 
Storage with "palloc". If it succeeds, it copies the old 
noncontiguous pages to the new contiguous ones. Pt 1 t 
fails, it calls "ceswap"™ to swap out the process. Nhen it 
returns to main memory, the CONT flag will cause its storage 


to be allocated contisguously. 


Cs Returned Values 


The values returned by this runction are not 


checked. 
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aie Error Conditions 


This function has no error conditions. 


Fe sysl.c 
la exec () 
as Parameters 


The current process's UVECTOR, PROC, and TEXT 
are implied parameters. Because this function is a System 
call, the array utargl}] in the UVECTOR contains additional 


arguments. See Ref. [ll]. 
Db. Functional Descristion 


This system call is used by the current process 
to invoke a new orogram. It cooies any frogram arguments to 
a buffer, unlinks from the old TEXT, frees its old main 
storage, establishes a mew TEXT if the new program has 
Shared code, acquires storage for the new data and stack, 
clears the region acquired, reads in the new datar copies 
the arguments to the new stack, and changes the memory 
management registers to make them compatible with the new 
address space. In UNIX “expand" is used to free the old 
main storage; in SUNIX and PSUNIX a new function, "“prfree", 
is used. In UNIX "estabur™ is used to validate the storage 
requirements of the new orogram; im SUNIX and PSUNIX 


"ceksize" jis used. 
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¢. ReturmedsaValges 


This system call returns to the caller only if 
it encounters an error. lf no error has occurred, it 


returns to the first instruction of the new program. 
G. Error Conditions 


This function returns to the caller og the 


storage requirements of the new orogram are invalid. 
ee exit () 
ae Parameters 


The current process's UVECTOR, PROC, aria) | eal 


are imolied oarameters. 
be Functional Description 


This function is the system call used to 
terminate the current orocess. It clears siaqnals, closes 
any ooen files, unlinks from the current TEXT, acquires a 
block on the swan device, copies the first 256 bytes of the 
current UVECTOR to the block, and frees main storage. In 
SUNIX and PSUNIX, old main storage is freed by “prfree," a 
new function. Because of the different method o f 
controllina swap spacer, SUNIX and PSUNIX use "Swfree" to 


free any Swaod space allocated to the process. 
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ce Returned Values 


This system call does not return to its caller. 
The next function invoked for this process is “wait"™ which 


completes the cleanucr. 
a.) CE RoGmcond tt lenis 
This system call has no error conditions. 
3. sbreak() 
@e Parameters 


The current orocess's UVECTOR and PROC are 
implied parameters. Because this function is a system call, 
an additional argument, the virtual address of the new end 


of the data, 1s found in the array utarg{]) in the UVECTOR. 
be. Functional Description 


This function is the system call used to change 
the size of the current process's data area. It calculates 
the new data size desired by the current process. and 
validity checks the current process's total storage 
requirement. If the requirement is not valid it returns 
without fulfilling the requirement. In UNIX, "expand" is 
used to establish the new region. In PSUNIX, "“dexpand" is 
used to change the size of the data. In SUNIX, Ghas 
function attemots to do the work itself. It puts the new 
size in pedsize in the current PROC. If the new size is 


smaller, it frees the excess storage. If the new size vs 
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larger, 1t attemots to Sseaun pena. Lf Vt failisvanit pecs 
Sceswao”" to acquire the soece bY swasoinma- In al} Systems 


the newly acauired space is cleared. 
ce Returned Mavues 


Values returned by thine System call are not 


checked. 
Gae, Error Gono tics 


If the new storage requirement is not. valid, 
this system call returns without allocating the storage. 
This will] usually cause the orocess to terminate abnormally 


because of a memory management error. 


G. text.c 
lee xswaolo,ttrosvm xSwaplop,ti»xcdsvess) 
ae Parameters 


In UNIX this function is called with three 
parameters. In SUNIX and PSUNIX, it is called with four 
parameters. es, faeee parameter is a pointer to the PROC of 
@ process to be swapped out of main memory. The second 
parameter is the memory free flag. in UNIX the thi¢ed 
Oarameter is the process's region size in 64=byte blocks. 
In SUNIX and PSUNIX the third and fourth parameters are the 


SrOCcess ' S Gata anc stack S$1Z26€S jn 64=oy7te blocks. 
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om Functional Description 


In UNIX this function allocates Swan soace (for 
the process and swaps it out. In SUNIX and PSUNIX this 
function allocates swap space only for those processes” that 
do not already have it. In all versions of the operating 
System, memory is freed if the memory free flag is set. 
This flag will not be set if this function has been called 


by “newproc”™ to create a copy of a parent process. 


Ce Returned Values 


The value returned by this fURCT1OS iS not 


checked. 


d< Error Conditions 


If swao space must be allocated but none is 
available, the message “out of swao space" will be sent to 
the console and the system will crash. I[f an output error 
occurs during the swao,r, the message "Swap error" will be 
sent to the console and the system will crash. 

eo. xfree() 


Be Parameters 


The current process's UVECTOR and TEXT are 


implied oarameters. 
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be Funct ional ebesen 15 ale 


This function relinquishes use of —themecwrcea: 
process's shared text. I[f the current orocess has no shared 
mext, this function just returns. If the curremtuecrocecs 
has shared text, "“xccdec"™ is called to decrement the TEXT's 
inememory use count. The TEXT's activesprocess use count is 
then decremented. I[f this count has reached zero and if the 
text segment is not to be retained, the TEXT'S swap space 


and the TexT itself are freed. 
ce Returned Values 


The value returned by {hoes function 1S moet 


checked. 
dweercor EComdit tons 
This fumcection has newerrormecena) Clogs. 
Se xal loelip) 
ae Parameters 


The parameter is a pointer to the inode of the 
text segment that 1s to be established or located. The 
current orocess's UVECTOR and PROC and all TEXTs are imolied 


oarameters. 
Oo. Functional Description 


nars function establishes the shared text 


segment requested by the current process. If the current 


(ar: 





process does not require shared text, this fumetion (feturos. 
If the process does require shared text, this function 
searches the array of TEXTs for a previously established 
TEXT for the requested seaqment. if ome is / founcdaies 
activew-process use count is incremented. If the requested 
segment 1S 1M main memory, the TEXT'S in=memory use count is 
also incremented and the function returns. If a TEXT has 
not been previously established, an unallocated TEXT is 
located and allocated to the text segment. Swap space is 
allocated for the text segment. The current process's 
address space is increased using “expand” to get sdace into 
which the text segment can be read. The text segment is 
read into memory and then it 18 written out to the swap 
seeace acquired for tit. The memory acquired for the text 
read is freed using "expand" in UNIX and "“"prfree" in SUNIX 
and PSUNIX. The address of the TEXT is placed in petextp in 
the current PROC. The current process is Swapped out with 
"xswap". Nhen it returns to memory, the text segment will 


Setturn with it. 


es Returned Values 


The value returned by this funet lon 1S not 


emeckede 


gd. Error Conditions 


If a TEXT must be allocated and one 18S not 


#4 


available, the message out of text" will be sent to the 


console and the system will crash. If swao sodace must be 
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allocated and none is available, the message "out of swap 
space" will be sent to the console and the system wil] 


crash. 
a. xccaec (xo) 
Be Parameters 


The parameter is a pointer to a PROC. The PROC's TEX? “swan 


implied araument. 
Dre Functional Description 


lf_the PROC has. no TEX? this  tumction ret lense 
it it has a TEXT, the TEXT's in=memory use count is 
decremented. If the count reaches zero, the memory occupied 


by the TEXT's text segment is freed. 
ce. Returned Values 


The value returned aiiby  .this functor eis aoe 


checked. 
Ge Frror Conditions 


This function hasS No error conditions. 


awe) Page .c 


1. ptbuild(tab,sizel,sizec,ad) 
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a Parameters 


The first parameter iS ac oimte put Cumoum eee. 
The next two parameters are the sizes in 64=byte blocks of a 
process's data and stack. The last oarameter is a pointer 
to an array containing the memory physical block numbers of 


@ process's paces. 
be Punnett onal Desemiot tom 


This function 1s present Honly. wig moun. it: 
puts the sizes and addresses of a process'sS Dages into the 


PAGET. The order within the PAGET is data pages first from 
a. 
low to high) virtual address followed by stack pages from 


high to low virtual address. Unused PAGET entries are 


zeroed. 
ce Returned Values 


The value returned oby this TUme t 11Om is not 


checked. 
Gaeerror Comditiogs 
This functiommhas Bo error conditions. 
e. ptsize(tab,sizel,sizec) 
a. Parameters 


The first parameter i$ a pointer to a PAGET. 
The last two parameters are the sizes in 64"byte blocks of a 


process's data and stack. 
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Dus Functional Descripnvtion 


This function is SresSemtumon eee oleae 1k 
puts page sizes into the PAGET. The order of s1zeS within 
the PAGET is data pages from low to high virtual address 


followed by stack pages from high to low virtual address. 


Gy Returned Values 


The value returned by this f UmiG om is mot 


checked. 


Ge Erroreclome!t)coas 


tmrserunction Nas mo error conditions. 


3. palloc(ptab,ds-ss,cont ) 


aie Parameters 


The first oarameter is a pointer to ae PAGET. 
The next two parameters are a process's data segment and 
stack segment sizes in 64-byte blocks. The last parameter 


1s the contiguity flaa. 


Ds Functional Description 


This function 16 e@fesemtumog ty. 1m FPSUNIX? It 
Seolls "“otsize”™ to put the page sizes into the FPACET, 
allocates main memory for each PAGET oage with a nonzero 
sizer and puts the starting block numbers of the allocated 
memory into the PAGET. If allocation fails for any opaqe, 


a1 | memory allocated for the process is freed. If the 


eu 





contiguity flag ts set», contiguous memory is allocated for 


both the data and stack pages. 


c. Returned Values 


If-allocatiomefor al!) pagesmis successtuly 7 vaus 
one is returned. If allocation fails for any pager, zero its 


returned. 


ae Error Conditions 


A returned value of zero indicates an allocation 


error to the caller. 


4. pfree(tab) 


ae Parameters 


The parameter is a pointer to a PAGET. 


b. Fumctionmal Desermnt) on 


This function is found only is PSUNIX. Lt frees 


the memory allocated to the oages itn the PAGET. 


Cs Returned Values 


The value returned by this hooec ton is not 


emnecked. 


as Error Conditions 


This function has no error conditions. 


Be 





5s Ppeooy lotooyatac) 


as Parameters 


The first parameter is aapointer to asthe oeriou. 
PAGET. The second parameter is a pointer to the destination 


PAGET. 


be Functional Description 


IBS —fURnCEVON VS5oresent Monty aminee OUND. Et 
copies pages pointed to by the origin PAGET to corresponding 
pages pointed to by the destination PAGET. A zero page 
block number in either PAGET terminates the copying. The 
number of blocks copied per dage is determined by the  s$1Ze 


of the origin page. 


ce Returned Values 


The value returned by this FunGe ¢ OM 1S mot 


checked. 


Gd. Error Concitions 


this function Pas No eproreconmo:itions. 


So eoGel | oc (or) 


a. Parameters 


The parameter is a pointer to a PROC. The 


PROC's TEXT is an imolied inout. 
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oe Functional Description 


This function 1S  peesenturom) ym) a.) oU luisa 
PoUNIX. It acquires memory for the process's UVECTOR, data 
segment, stack segment, and, 1f necessary, shared text 
segment. Space for the text segment is acquired only if the 
text 1S not main memory resident. If any allocation fails, 


all memory previously allocated is freed. 


ce Returned Values 


If all allocations are successful, the memory 
block number of the first block allocated for the UVECTOR is 


returned. If any allocation fails, zero is returned. 


a. Error Conaitions 


A return value of zero indicates an error to the 


caller. 


7. oswao(daddr,tabd,num, flag) 


ae Parameters 


The first parameter is a block number on the 
Swap device. The second parameter is a pointer to a PAGET. 
The third oarameter is the number of oages to swap. The 


last parameter is the readewrite flag. 


be. Functional Description 


This function is present only in FOUN Ia nt 


Swaps the indicated number of pages to or from main memory. 
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If the read-=write flag is set, the pages are sSwapped into 
the memory locations specified by the PAGET. If it is not 
set, the pages are swapped to the Swap device beginning at 


the specified block number. 
ce. Returned Values 


The value returned by this FunG C1 On 1S not 


checked. 
a.) GGtemmconditions 
thas tuncte Om nas Morler ror comenuToms. 
8. prswap(ro) 
a. Parameters 


The parameter is a pointer to a PROC. The 


Beuc s TEXT is an imolied inout. 
ole Functional Descriotion 


This function is opresent only in SUNIX and 
PSUNIX. It swaos a process's UVECTOR, data segment, stack 


segment, and, if necesSary,sr text segment into main memory. 
ce. Returned Values 


The value returned by this function is not 


checked. 
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Gls Error Goncd1t1oms 


If an input error occurs during the swap, the 
message "Swap error” will be sent to the console and the 


system will crash. 


ime 6bio.c 
1. ponysio(strat, abo, dev, rw) 
@e Parameters 


The ftvrst parameter 1S a4 “oOoI1nter to the i730 
initiation routine routine for the device to be used. The 
second parameter 1s to a buffer header that contains control 
information about the I/0 operation to be performed. The 
third parameter is the device identifier. The Fourth 


Darameter 1s a read/write flag. 
b. Functional Description 


This function computes and validates the 
Dhysical address of an I[/0 area within the User address 
space. If the address is valid, this function calls the I/O 
Initiation routine to start the I/0 operation. In PSUNIX, 
this function determines if the I/0 area crosses a page 
boundary. If it does cross a boundary, this function calls 


"contig()" to make the requesting orocess contiguous. 
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c. Returned Values 


The values returned by this fume © on are not 


checked. 


Ge Error Conditions 


If an I/0 error occurs or the requested 
operation iS not valid, an error condition is signaled by 
setting a bit in ufuerror in the requesting process's 


UVECTOR. 
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APPENDIX Cs: SYSTEM BENCHMARKS 


A, BENCH 


chdir /usr/emery 

sh old 

chdir ken 

ec “0 -c sip-c 

il « 

ea, amr 

ed ipc.ec </usr/oench/edemda >/dev/nul | 
chdir /usr/bench 

ee, -0 rftest.c 

bas tower<towerin>/dev/nul | 

od /usr/sys/conf/m45.s >/dev/nul } 
co /unix /dev/nul ] 

chdir /bin 

sum *>/dev/nul ] 

wait 

chdir /usr/emery/ken 

Gm SIiDe.0 

chdir /usr/bench 

rm @e0ut 


cee, SENCH2 


chdir /usr/emery 

sh old& 

chdir ken 

ce “0 -c sio.cd 

Gd «- 

€q odmr 

ed ipc.ec </usr/bench/edemd >/dev/nul1& 
chdir /usr/bench 

€e -0 rftest.c8& 

bas tower<towerin>/dev/nul]& 

od /usr/sys/conf/m45.s >/dev/null& 
co /unix /dev/null& 

endir /bin 

sum *>/dev/null& 


wait 
chdir /usr/emery/ken 
rm slp.0 


chdir /usr/bench 
rm ae Out 
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